Ham Radio 2000/Ham Radio 2000.iso/ham2000/satellit/pacdoc/uo22info.txt

Internet Message Format | 1994-08-24 | 43KB

From      : g0k8ka
To        : all
Title     : Welcome!
Keywords  : UO22
Uploader  : G0K8KA
Uploaded  : Tue Feb 04 11:25:49 1992
__________________________
Welcome to UO-22.

I hope that the rapid switchover hasn't inconvenienced too many of you
with messages getting trapped on UO-14. The switch to UO-22 has two
important advantages which we should keep in mind:

More directory entries - 800 to be exact. This means that messages will
have longer lifetimes, and we can consider upping the default lifetime
to 7 days for bulletins, while recommending shorter lifetimes for other
mail. (A release of PFHADD is required, I know). Of course, unless we fill
up to 750 messages the lifetimes will not particularly matter.

More uplink channels - Because we are not supporting non-amateur activities
on UO-22, we can switch both receivers to AMSAT uplink channels. I would
recommend that we try to concentrate uplink activity on what was the old
UO-14 uplink, 145.975 MHz, and use 145.900 MHz for overflow. This reduces
interference on 145.900 to AO-13 users and the microsats. I think that the
best way to divide uplink activity is to have broadcast requests and other
PB operations on .900 while uploaders are on .975. I know that this would
be difficult for automated stations, and don't expect everyone to comply.
On the other hand, if manned stations try to do it, then it will improve
performance for everyone.

There are still several outstanding matters that I have to sort out:

PB new release with fixed SLIST and archiving of PFHDIR.PFH
PFHADD new release with user-entered EXPIRE_TIME
Coherent FILE_TYPE (particularly file type 12!)
Reduction of redundant broadcast transmissions (flight s/w change)

And there are technical matters which will require input from others
at UoS or within AMSAT:

on-board image compression for CCD camera
power management software to allow HPA operation

All of this will get "medium" priority, with high priority reserved (in my
case) for the KITSAT-A mission which is moving into the flight-hardware
stage.

JWW

From      : g0k8ka
To        : all
Title     : UO-22 Status
Keywords  : Broadcast Server
Uploader  : G0K8KA
Uploaded  : Mon Feb 17 12:02:20 1992
__________________________
You will have noticed that the UO-22 broadcast server hung up on Friday
afternoon, and now it is reloaded.

In between, Neville took a memory dump, and on Sunday I managed to find
a bug in the broadcast directory server code. This bug completely explained
Friday's hangup. It may also have been responsible for some of the problems
on UO-14 earlier in the year.

The new version of PBP/DBP also includes a feature which should make it
quicker to fill in the last few holes of a file: whenever the satellite
receives a hole-fill request which would result in the transmission of
1024 bytes or fewer, that request does not go to the end of the queue, but
to the beginning. I would be interested to hear your reactions to this feature;
it might result in a few seconds longer wait for the user who is making a
"large" request, but can cut as much as 90 seconds off the waiting time for
the last few holes in a file. [This was a relatively simple modification
to the server code, and can be removed if you all don't like it.]

I will try to release PB again this week with fixes to the bugs. I know it's
been a long time, but we've been very busy here.

JWW

From      : vk5hi
To        : ALL
Title     : Directory FIX (Short-term)
Uploader  : VK5HI
Uploaded  : Fri Feb 21 23:30:15 1992
__________________________
To: ALL                                                    21st February 92
From: Colin VK5HI
Subject: Directory Problem

I also experienced the R6001 Null pointer assignment during the week,
after noting (frustratingly) the fact that I could not  get a DIRECTORY
update. I also noted that my txdelay also became inordinately long, as
the TX was holding up a lot longer than normal.
I noted that I had 68 holes in my DIRECTORY. Therefore I experimented
a little and have deduced a "SOLUTION" to the problem.

1. Make a copy of your PFHDIR.HOL file.
2. Using a text editor on PFHDIR.HOL delete the hole information as follows

0 pfh header received
0 pfh file length
8 holes                            Change from previous value
698437067, 698437075    ]
698443271, 698444395    ]
698444539, 698447527    ]
698447547, 698447754    ]          Retain the last 8 LINES of the FILE
698447989, 698448000    ]
698448028, 698448046    ]
698448080, 698448091    ]
698457600, 4294967295   ]          Under NO CIRCUMSTANCES change the LAST
                                   Line. Contains Time and Date and delimiter
                                   for PB Program

When modified and you re-boot PB you will see a message that you have 8 holes
in your directory.

                   de Colin VK5HI.
PS:
For reference my unmodified file WAS as follows

0 pfh header received
0 pfh file length
68 holes
0, 697496831
697497182, 697497302
697505671, 697507203
697507220, 697508304
697508704, 697511243
697511323, 697511386
697511515, 697514731
697514759, 697520427
697520450, 697520873
697630602, 697630709
697670874, 697673826
697677652, 697680002
697680079, 697680079
697681253, 697685729
697686126, 697689084
697695111, 697708298
697714490, 697714496
697714516, 697723794
697726713, 697732005
697744769, 697744830
697749339, 697766498
697767406, 697770304
697770399, 697778918
697779197, 697779210
697779228, 697779338
697782357, 697787970
697792488, 697792599
697804780, 697804781
697805181, 697807961
697808442, 697810810
697816927, 697818277
697823068, 697823109
697833628, 697833657
697833858, 697833904
697842401, 697845704
697847657, 697919566
697948225, 697950954
697973045, 697982540
698003957, 698003990
698008058, 698098605
698098616, 698100081
698100093, 698101201
698107360, 698118637
698122374, 698124231
698128390, 698128399
698159575, 698166391
698166402, 698177641
698178366, 698181606
698185601, 698218736
698218748, 698218768
698279041, 698279407
698279474, 698282953
698284068, 698285237
698289792, 698310063
698310133, 698322321
698346000, 698346570
698346632, 698346651
698352693, 698352710
698369605, 698369614
698369715, 698370492
698437067, 698437075
698443271, 698444395
698444539, 698447527
698447547, 698447754
698447989, 698448000
698448028, 698448046
698448080, 698448091
698457600, 4294967295

From      : g0k8ka
To        : all
Title     : be Good, use G
Keywords  : PB GRAB NEVER
Uploader  : G0K8KA
Uploaded  : Thu Feb 27 09:27:35 1992
__________________________
This is just a remiNder that you should Not mark messages with N uNless you
Never waNt to read them. A messaGe which you miGht want to read later should
be marked G so that you take advantaGe of anyone else in your footprint
downloadinG the messaGe. MarkinG with a G does not cause your station to
to transmit any requests, it just makes sure that you Grab anythinG cominG
down from that messaGe.

Clearly, the satellite is filling up again, and we must make sure that we
use all the existing efficiency-enhancing facilities before throwing up
our hands in disgust.
JWW

From      : g0k8ka
To        : w0sl
Title     : Batch processing
Keywords  : PB
Uploader  : G0K8KA
Uploaded  : Fri Feb 28 13:50:55 1992
__________________________
Roy,

I spent about 20 minutes looking through my DOS 5 manual for the
"if exist" syntax. I guess I should just have tried it! Clearly,
it should be there for the PG run, as it saves some thrashing.
It is probably worth putting it in dofile.bat at the very beginning
to overcome the problem which arises as follows:

You download a message nnnn,
but before you exit PB and process postpass.bat
You press V on the message and this causes PB to (attempt)

dofile nnnn

to create msgs\nnnn.msg for viewing.

This can, in effect, remove nnnn.dl, so that even though

dofile nnnn

is in the postpass.bat file, nnnn.dl isn't around to look at.
So, it is worth having an if exits %1.dl at the beginning of dofile.bat,
to save those "file not found" errors.

I'm glad to see that you're taking advantage of the hooks. It is perhaps
not as seamless as the stuff in NET, I just don't know. Eventually, with
a KISS/AX.25 implementation inside PB, I will be able to move the uploading
in there and really get the thing working efficiently. For now, I suspect
that it will allow gateways to use PG/PB if they don't want to use NET for
any reason.

It is my experience on a 33 Mhz non-caching 80386 machine that I can run
PB under Windows 3, and I certainly used to run it under DesqView. I won't
be supporting an INT14 driver (e.g. MBBIOS) in any foreseeable future, unless
I hear some very good arguments in favour.

Thanks again for keeping the other users informed of the uses you've found
for postpass.bat and dofile.bat.

JWW

From      : g0k8ka
To        : all
Title     : Feature Found
Uploader  : G0K8KA
Uploaded  : Tue Mar 03 21:10:20 1992
__________________________
When all else fails...

I was wondering why I didn't make any facility for manipulating messages
which are not in the directory. And of course, I did.

From the Main Window (e.g. not the Directory View window), typing
A, N or G brings up a prompt window (top of the screen) asking you
for a message number.

To get rid of ghosts, type N and then the message number. This seems to work
here.

JWW
From      : g0k8ka
To        : zl1biv
Title     : PFH Mysteries
Keywords  : PFHDIR.PFH PFH_VAL.EXE
Uploader  : G0K8KA
Uploaded  : Wed Mar 04 14:11:15 1992
__________________________
Jeff,

The pfh_val program is simple in concept: You give it a file name, and a
PFH Item ID code. It returns - as errorlevel - the first byte of the Data
portion of the indicated PFH Item. This will ONLY be clear if you look
at the PFH specification.

The PACSAT File Header (PFH) is really a collection of Items. Each Item
has the same format

Item ID | Data Length | Data

Item ID is an integer identifying the item, the file type has ID number 8.
These ID numbers are listed in the PFH protocol specification.

So when I want to find out the file type for 8003.dl, I run

pfh_val 8003.dl 8

and it returns an error level of 1 for file type 1, 2 for file type 2,
etc.

This is only really useful for PFH Items which have one byte of Data,
since error codes greater than 255 cannot be used.
------

PFHDIR.PFH

This is a file containing valid PFHs as described by the protocol. They
are just placed in the file one after another. You will notice that any
valid PFH starts with AA 55, and you can see that at the beginning of the
file. It is also true that every PFH ends with 00 00 00, e.g. the PFH_END
item with data length 0. However 00 00 00 can also appear elsewhere in
the PFH. The only sure way to find the end of a PFH is to

(1) throw out the 55 aa
(2) read two bytes of Item ID
(3) read one byte of Data_length
(4) read Data_length bytes of data
(5) if Item ID is 0000, you're done
    else loop to (2)

That's off the top of my head, but I think it's right.

-----

Hope that's all interesting.

73, JWW


Jeff, in PFH_VAL, the ending parameter value will return many different
values.  For example, we already know about the parameter values 8 and 25
from reading through DOFILE.  It apears that the parameter 4 will
return the file length for example.  What do other values return?  I have
gotten values returned from the following parameters but don't know what
they mean:

     1-11, 16-25, 34-35 and 38

Are there more?  This could be a goldmine!

Other items:

1. A UO22 image file, type 63, fails the DOFILE compression test.
These image files return a blank, (or something) but not a 0 for
uncompressed.  If digits are not returned, what is returned, null,
blank, etc.?  Is it consistent?  The test for compression in this case
takes the first branch, which happens to be the "uct" branch.  DOS
evidently does something funny when a non numeric errorlevel is returned.
Therein lies another small item as follows:

2.  The :uct label sets C=UCT, but all subsequent tests of the C variable
check for C being UNK rather than UCT.  The :uct label should SET C=UNK.

3.  Label :error should be changed to :err to agree with the "goto err"
statements.

None of this should affect users who are using DOFILE as issued.  I only
ran into this while trying to "hang onto the hooks" a routine to move the
image files somewhere else for processing and viewing.

73, Roy -- W0SL

From G0K8KA

ONBOARD LOG FILE TYPES

We are presently testing a version of PB with complete "select equation"
facility. E.g. you can define what messages are to be blocked, auto'd,
prioritied, or grabbed, and you can define all of the 12 function
keys to show custom views of your directory file.

This has brought the "File Type" problem back up to the top of the
stack, and with the last reload we have taken action with regard to the
onboard logs.

All spacecraft-generated log or data files will be given new file
types, greater than 200. This will make them easy to identify and
filter out with a select equation

((file_type >= 200) && (file_type != 255))

The log file list for UO-5 follows:

200    configuration files uploaded from command stations
201    AL FTL0 / PB activity logs
202    BL Broadcast logs
203    WD Whole Orbit Data
204    ADCS logs
205    TDE data
206    SCTE data
207    Transputer logs
208    SEU logs (ELTLOG)
209    [CPE files on UO3]
210    Battery Charge System logs
211    IMAGE FILES

I don't think this should really bother anyone, and we had to take
the plunge and do it eventually. I think that coordinating it with
the new PB release is the best approach.

OTHER FILE TYPES

We also need some new file types for user files. Here are those which
came from previous consultation.

12 - Multiple files, one or more non-ASCII (currently called "miscelaneous
     binary")
13 - Multiple files, all ASCII text
14 - GIF Format
15 - PCX Format
16 - JPEG Format

TYPE 12 - This has been in use already, and the new definition just clarifies
what is going on. One or more of the files in the archive is unlikely to look
good if displayed or printed as ASCII text.

TYPE 13 - on the other hand says that all of the files included are likely to be
subject to straight ASCII printing and display. This might be used for multiple
newsletters zipped into one message.

The type 12/13 distinction was suggested by users, and I think it makes sense.

TYPE 14, 15, 16 - These seem to be the commonly-used image file formats. Both
JPEG and GIF also include compression, but the compressed thing is always an
image, and the files are typically sent to a single application program which
both decompresses and displays them. Hence, they are file_type and not
compression_type.

COMPRESSION TYPES

Compression type 03 has already been provisionally allocated to LHA
compression. Are any other compression types needed at the moment?

I will take all input on these matters next week and then get a specification
update out by month end.

73, JWW

From      : g0k8ka
To        : all
Title     : Please use "ALL" for bulletins
Keywords  : ALL BULLETINS KEYWORDS
Uploader  : G0K8KA
Uploaded  : Sun May 03 11:45:08 1992
__________________________
I would like to reiterate my plea that people use the word "ALL" as the
address for bulletin messages - even selective bulletins. You can then use
a special key-word to separate your bulletins into selective groups. The
new select equation feature in PB makes it possible to select any group
of messages based on any fields, and it would be nice to think that
I could select all bulletin messages by using the equation

(destination = *+all+*)

and then further subdivide using keywords if I really need to, e.g.

(destination = *+all+*) &
(
     (keyword = *+satgate+*) |
     (keyword = *+PB+*) |
     (keyword = *+KENWOOD+*)
)

My reasoning is that by having "ALL" as the destination, we have a clearly
selectable separation between point-to-point messages and point-to-multipoint
messages. The keyword field leaves us the possiblity of further subdivision
of point-to-multipoint messages on a case-by-case basis.

Comments?

JWW

From      : g0k8ka
To        : all
Title     : Various responses
Keywords  : PG PB TNC
Uploader  : G0K8KA
Uploaded  : Fri May 08 08:49:10 1992
__________________________
Sorr, but I haven't got time at the moment to investigate completely the queries
coming on the heels of the latest PB release. Here are my immediate thoughts
after scanning this morning's mail:

PG - Until proven otherwise, TNC hangups cannot be the fault of PG. If
the TNC firmware was sound, it would not hang up. Now, if your TNC hangs
up while it has PG flow controlled (e.g. with handshaking lines telling
PG not to do anything), then PG and your computer will also "hang." There
should be some timeout in PG which overcomes this, but there isn't. We
sometimes get these hangups here, even though we are using 1.1.7b, which
is not surprising, since all of the firmware for TAPR boards is of same sire.
Perhaps N4HY can tell us how performance is on his system, which has nothing
in common with TAPR firmware.

Upload performance - Rob's measurements of smoothed round trip delay begin
to show what parameters would be necessary for good steady flow on the
uplink. Of course, good, steady flow is only "good" if nobody else is
transmitting on top of you and trashing some of your packets. Independent
of TNC hangup, we must be seeing some uplink channel collapse when people
try to upload messages on the same channel that others are using for
broadcast requests. Make an effort to use the "right" channel for the "right"
activity - I must say that I can't remember what we agreed upon.

PB AND AO-16 - I no longer maintain a release version of the older PB code.
It is one of my weaknesses that while engaged in development, I usually
can't even lay hands on good source code for versions made yesterday, let
alone versions made months ago. On the bright side, NK6K has the new satellite
code for the 1200-baud birds and should be getting to it in the next couple of
weeks.

PB AND "Error -1 writing directory" - Make sure that your old .PFH files are
not write protected. I found a most frustrating situation happens if you
write protect a .ACT or .HOL file. Try it.

PB920430 not loading - G4WFQ. Very strange. I am convinced that this has
something to do with PB.CFG. Try moving everything to a fresh directory,
cd to that directory, and run PB. Try the (annoying) standard compatibility
tests, e.g. removing TSRs, Fastdisk, etc. I routinely run PB under windows
3.1, which I reckon should stress it pretty well in the compatibility stakes.
On the other hand, you may somehow have received (twice) a corrupted version
of the program. This seems very unlikely, but maybe you can get someone to
compare .ZIP checksums with you.

JWW

From      : g0k8ka
To        : pe1chl
Title     : FTL0 Blocks self
Keywords  : FTL0 QAX25
Uploader  : G0K8KA
Uploaded  : Fri May 08 08:49:19 1992
__________________________
I am not at all surprised that your upload sessions and your download
sessions are related at the upper level, since they are both implemented
by the same task in the satellite. If the task is asked to do something
time-consuming (e.g. a select) then it won't be able to look at its input
queue and packets will build up. Presumably the same thing would happen in
the NET if you went off to search the disk for some set of files.

Of course, if two people are connected, and one of them does a select, the
effect knocks on to the other person. There are two solutions to this: (1)
have no time-consuming atomic operations or (2) have every up/down-link process
operating as a separate task. (1) is fruitful if I could speed up select.
When I implemented ftl0 for UO3, with 256kbytes of RAM, (2) was not an
option. Since I'm not really pursuing FTL0 at the moment, (2) is not likely
to be an option on UO5 either.

This effect - the blocking of FTL0 by itself - is more important than the
possible blocking of FTL0 by PBP. In fact, the AX.25 driver takes one
frame from PBP, and one from FTL0 in a round robin (along with any other
connected or UI using processes). (NK6K to comment?)
JWW

From      : g0k8ka
To        : fo5lq all
Title     : Directory questions
Keywords  : PB PFHDIR.HOL HIGHTIME
Uploader  : G0K8KA
Uploaded  : Sat May 09 11:29:59 1992
__________________________
Alain,

The effect of "hightime" may be achieved by deleting PFHDIR.HOL and
running PB. You will be prompted for the number of days of directory
entries you want to get. This WILL NOT result in the loss of any
already-received directory entires. It is a perfectly safe way to
recover after being off the air for a week. It overcomes the need
to have to receive 800 directory entries when you first come on the
air.

JWW

From      : g0k8ka
To        : vk4bbs all
Title     : Error -1, and FILES=
Keywords  : PB
Uploader  : G0K8KA
Uploaded  : Sun May 10 09:25:47 1992
__________________________
Brian,

The error messages you are seeing are caused by PB not being able to open
a file to write the directory entry to. My first intuition was that you
have write protected the files - you check this? My next feeling is that
you must not have

FILES=30

or a similar line in your CONFIG.SYS file for your machine. Many complex
applications need a lot of open files, and this is a good thing to
put into CONFIG.SYS anyway.

The "error <x> writing directory" message should be accompanied by a
more-complete report in a file called "pberror.log" Do you find such
a file on your disk? If not, then the FILES= is the most likely culprit,
since if there are not enough FILES= to open the directory file, there
probably aren't enough to open the pberror.log file.

If you do have pberror.log, please send it to me.

JWW

From      : g0k8ka
To        : all
Title     : PB920430 bug list
Keywords  : PB
Uploader  : G0K8KA
Uploaded  : Fri May 08 12:09:01 1992
__________________________
Oops.

It looks like an undocumented feature of the new compiler I used to generate
the PB920430 release means that it will not run on 8086 machines. Once we
have found all the weevils in this version, I propose to make a quick update.
This will likely be at the end of the month. Thus far, we have

A) keywords "or" and "and" not recognized by select equation parser.

B) no "pbhelp.hhh" file in release.

C) desire for some file, e.g. PB.TNC to get sent to the TNC before putting
   the TNC in KISS mode.

D) clarification of documentation r.e. meaning of BLOCKFTYPE

We also seem to have a query from the field r.e. errors when writing
directory files. Anyone else seen this?

I know that I also owe you a new release of the valid file_type and
compression_type assignments.

JWW

From      : zl1aox
To        : g0k8ka
Title     : F11 & F12 with QEMM
Keywords  : DOS 5.0 Qemm Ver. 6.03 OK
Uploader  : ZL1AOX
Uploaded  : Sat May 23 10:44:16 1992
__________________________
TO: Jeff and Marcel
DE: ZL1AOX
RE: F11 & F12 keys.

Geoff, VK2AIT has mentioned in a msg that QEMM was affecting DOS
5.0. I checked my 486/33  system and found that the F11 & F12 keys
worked OK once I had removed QEMM ver 6.00.
I have now obtained QEMM ver 6.03, and F11 & F12 work with DOS
5.0 and with QEMM as the memory manager. So happily the problem
is no more.
73 Ian, ZL1AOX.
PS, Tnx to Geoff VK2AIT

From      : g0k8ka
To        : all
Title     : Present a good image.
Keywords  : IMAGE GIF
Uploader  : G0K8KA
Uploaded  : Wed Jun 03 11:34:32 1992
__________________________
At least in the USA and UK, there are large numbers of very young radio
amateurs and increasing numbers of schools experimenting with amateur
radio. Please do not place any files on OSCAR-22 which would not be
appropriate this young audience.

Parents and teachers may get their first impression of amateur radio from
a file downloaded from OSCAR-22. We would like that to be a good impression.

Of course, there are also national and international laws, and IARU
guidelines concerning the appropriate content of amateur radio
communications. We can avoid petty legal and moral arguments if
we apply common sense and remember the large and diverse audience
who will receive the files that we post

Thank you,

Jeff Ward, G0/K8KA
University of Surrey
UoSAT Spacecraft Engineering Research Unit

From      : oh1kh
To        : sv5alq
Title     : PB & TX
Keywords  : restart_delay
Uploader  : OH1KH
Uploaded  : Sun Jun 07 17:22:17 1992
__________________________
Hello....

Seems that you have too short "restart_delay" on PB.CFG.
It leads to broblem that TNC does not get KISS-command "Fullduplex on".

STA led blinks, but no TX beause there is continous carrier on RX side.


Try first to double "restart_delay" value.


I did have same kind of broblem when I started new directorys for AO16
and LO19 just a couple of days ago. I did copy all from current UO22
pb-dir where I have restart_delay 5. This is far too long, it should work
so small as 2. How ever I use 5.

But SURPRIZE !!! When I copied all to ao16 & LO19 directorys and did change
ONLY satellite call IT DIDN'T WORK !!!
I had JUST same broblems as you!

I HAD TO INCREASE restart_delay up TO 60 !!! This is amazing !!

I do have same equipments, only difference is that PB.CFG and other stuff is
on other directory and that 9600-RUH modem is replaced with 1200-RUH modem.


How ever PB DOES START FASTER ! Who can explain this ???


There is no broblem now, as I know how to go around it but something VERY
MYSTERIOUS is behind PB.CFGs that are in different directorys.(Even when they
are copies from same mother-cfg).

73'Saku  OH1KH

From      : g0k8ka
To        : all
Title     : Where the time goes.
Keywords  : PB AL DIR
Uploader  : G0K8KA
Uploaded  : Tue Jun 16 08:52:32 1992
__________________________
Factiods:
This data is compiled from the UoSAT-OSCAR-22 AL files from the month of May.
Any enterprising programmer can generate this much and more from AL files.
This data only covers FTL0, the connected-mode services.

Uploading:

169 stations each uploaded at least 1 message.
In total, these stations used 209357 seconds of connect time.
This is 1238.8 seconds per station.

Downloading:

10 stations used FTL0 downloading at least once.
In total, these stations used 7427 seconds of connect time.
This is 742.7 seconds per station.

Directories:

14 stations used FTL0 directory service at least once.
In total, these stations used 57219 seconds of connect time.
This is 4087.07 seconds per station.

Further analysis:

There are 19 stations who use either FTL0 downloading or FTL0 directories.
These stations are roughly 10% of the user community.
Not including their uploading, they consume 24% of all FTL0 activity.

Comments?
From      : g0k8ka
To        : g4wfq
Title     : Dir Direction
Keywords  : PB
Uploader  : G0K8KA
Uploaded  : Wed Jun 17 09:56:30 1992
__________________________
Dave,

Unless I'm mistaken, the directories are presently updated from oldest to
newest. Did you mean that you want them updated the other way, e.g. newest
to oldest?

At any rate, the updating of directories is done just like the filling of files,
so reversing the fill order (which would be like filling in the end of the file
first) would be pretty difficult. Sorry.

I am planning to implement a periodic broadcast (every x seconds) of the
last y minutes worth of directory entries, to stop some of the directory
requests that are being transmitted. (That was why I have PB move on to
directory fills _after_ finishing files, so that you take maximum advantage
of other people's directory fills before requesting your own.)

73, JWW

From      : G0KO5I
To        : ALL
Title     : File Type Numbers
Uploader  : G0K8KA
Uploaded  : Mon Dec 14 18:46:17 1992
__________________________
To All UoSAT-22 users:

              A couple of weeks back I was asked to provide a
current list of the file type numbers used here on UO-22. In
consultations with Jeff Ward the following list has been produced.

I hope that you find it of value.

73

Doug Loughmiller, G0/KO5I

__________________________________________________________________


REVISED 20 September 1992

     0   ASCII text
     1   RLI/MBL message
     2   RLI/MBL import file (multiple messages)
     3   UOSAT whole orbit data
     6   MSDOS .EXE file
     7   MSDOS .COM file
     8   Keplerian Elements (NASA format)
     9   Keplerian Elements (AMSAT format)
    10   DELETED
    11   DELETED (?)
    12   Multiple files (one or more non- ASCII)
    13   Multiple files (all ASCII)
    14   GIF format
    15   PCX format
    16   JPG format
    17   Confirmation Message (to be described later)

   200   Config. files U/L from command stations
   201   AL FTL0/PB activity logs
   202   BL broadcast logs
   203   WD whole data logs
   204   ADCS logs
   205   TDE data
   206   SCTE data
   207   Transputer logs (including EISLOG)
   208   SEU logs (ELTLOG)
   209   CPE files (UO3)
   210   Battery charge logs
   211   Image files
   212   PL* (SPL logs)
   213   CU* (PCT Log files)
   214   PC* (PCT command logs)
   215   quick look image files.

   255   ESCAPE

FILE_TYPE alone conveys NO information about file compression, except
for file formats which imply their own _internal_ compression (e.g. GIF,
JPEG).


From      : g0sul
To        : all
Title     : A plan, but no schedule
Keywords  : PB PBP DIR BBS SATGATE G0K8KA
Uploader  : G0SUL
Uploaded  : Tue Jan 12 19:40:20 1993
__________________________
Hi everyone.

Sorry I haven't been participating in the discussions about enhancements
which may or may not be needed on UoSAT-OSCAR-22 and in the PB software.
I've been working on my PhD dissertation, which is a necessary evil at the
moment. Writing about the early implementations of all this software is
much less compelling than tinkering with the software, so I am planning
some tinkering.

SPACECRAFT CODE

First we have to have a stable platform from which to work. We're trying
to get some new (and mostly unchanged) code up and running on UO-22, but
we've had crashes the last 3 times we tried. Unfortunately the crash dumps
haven't revealed the cause of the problem yet. Rather than spending a
lot of time and/or money writing a 50-station PB and PG simulator so that
we can reproduce this crash on the ground, we are going to do another
"planned crash" as soon as possible.

Once we have located and fixed the problem, we will move along to some
modifications.

We know (and have known since the specification of the protocol)
that a major source of inefficiency on the downlink is the fact that
PBP does not optimize hole lists. If you and I both request the same
portion of a file or the directory and our requests are in the PB list
at the same time, the requested data will be sent twice.

The quick fix will be to remove requests from the PB list after they      (1)
reach the front, rather than letting them roll around to the end of
the list. This simple change will make sure that the requests are
"fresher," which should cut down a bit of the overlap.

The real fix is to optimize hole lists, and this will also be done.       (2)
Directory and file hole lists will be optimized. This will be essential
if we want to download pictures from KITSAT after the BBS is opened.

The third thing up for implementation is cutting the directory space      (3)
into two separate parts so that only BBS stations have to get the directory
entries for BBS files. We are looking at fixes that will not require users
to update PB, but would require BBS operators to update or patch
PB.

GROUND SOFTWARE

There is an updated PB running at a few stations and here at UoS, but it
is suspected of having a lurking, unreproducable bug. So I'm holding off
on a general release. There is only one amazing new feature - the downlink
quality meter. Perhaps by the time it's released, I'll stop it from
sending requests when the PB queue is full, too.

As Rip pointed out in a recent message, your all part of an experiment.
Unfortunately the experiment is still running, but I'm having to take time
out to write about progress thus far. Sorry.

JWW

From      : G1NBR
To        : ALL
Title     : Tick, Tick, Tick.
Keywords  : OBC Loader
Uploader  : G0SUL
Uploaded  : Thu Feb 18 12:43:43 1993
__________________________

To ALL,

UoSAT-5's back after a night of ticking as you'll have heard.

So what is this ticking? I've seen several people asking the question,
and as I wrote this ticking program, I'll try to explain.

When the OBC is rebooted it reverts to its low level 'bootloader'. This
is used to load the first layer of software which consists of the OBC's
'Kernal' and the 'Loader'.

When these programs are started, the OBC can be loaded very quickly.
During the loading process, the Loader can produce diagnostic information
in the form of 'Ticks'.

When you see the OBC ticking, it's being loaded or waiting to be loaded.
The information in the tick messages will change as loading progressed
and you can tell this mostly from the first letter following the word
'Tick':

'G' First stage of loading, called 'Ghost' version.
'N' Second stage of loading, called 'Non-AX25' version.
'Q' Final stage of loading, called 'AX25' version.

When the OBC seems to 'come to life' after a reload, loading is actually
not finished because several tasks still need to be loaded, but the minimal
system for the store and forward is running, allowing PB to be used. Later
when all the tasks are running, they produce the normal status messages you
see on the PB message screen.

So, watch for those Ticks! If it's all as clear as mud, ask me again.

73s
Marcel, G1NBR, UoSAT.

PS. The reason for the reload was to eliminate some bugs we found and move
to a 'Version Controlled' version (!?).


From      : g1nbr
To        : vk2pk
Title     : Select 'feature'!
Keywords  : PB select
Uploader  : G0SUL
Uploaded  : Fri Mar 19 18:31:27 1993
__________________________
TO: VK2PK
DE: G1NBR
Thursday, 11:15 GMT.

Hello Karl,

Thanks for your message, it's always good to hear from people who
do new things with these equations.

The quick answer is Yes, you can fix it.

The equations have a default limit of 300 bytes, chosen so that most
equations fit and don't take up too much space. (The problem is that
you don't know beforehand how big the equation is going to get.)
There is an override which can set the default size to whatever you
need - smaller to save memory and larger to cope with big equations.
The command is placed in the pb.eqns file outside the equation
definitions and looks like this:

     (F11 NormalEquation
     :
     )

     (500 equationsize)

     (F12 BigEquation
     :
     )

     (100 equationsize)

You must put the size *before* the command because the equation
parser works in 'Postfix', like Forth. Once you use the equationsize
command it keeps the size you set, so you might want to turn it down
again (using a second command as shown) if you go on to define any more
equations.

You might also consider making a different equation using the features
'maskdone' to select downloaded messages and 'getenvar' to get the name
or the time of the last message read. The environment variable would
need to be set to the correct value before running PB, which is
something your program might be able to do.

There is a new release of PB coming out but nothing revolutionary as
far as the select equations go.

93/03/19 PS: During the course of testing the above, I found a bug in
the select equation parser. The bug is tripped by having an equation
that's longer than 500 bytes (or so) of text. The results are
unpredictable. The bug can be positively identified if disabling the
select command in pb.cfg makes it go away.

The thing about 'equationsize' is still true and should work - you may
just be lucky and not trip the bug.

Let's see what happens when you try this and we'll take it from
there!

Sorry about the delay in replying...


73s, Marcel, UoSAT.


From: G0SUL 21-4-93
~~~~~~~~~~~~~~~~~~~
Sorry for the short-notice reload of UO-22. Full operation was restored
after only one interrupted orbit.

The 20 April reload of UO-22 brings in some minor new features.

1)  "Sked", which produces a periodic status message, is a facility
which allows the command station to schedule command operations at
any time in the future. It creates log files which will be type 216,
and are of no interest to users.

2)  PBP, the broadcast server has had some new features added.

2.1) CL files

The server can now keep track of all the stations who have issued
broadcast requests each day. This information is kept in RAM and
written to a file once per day. The file will be named CLyymmdd and
will have file type 217. The format of the file is an array of 6-byte
strings. There will be a maximum of 400 callsigns in this array (at
the moment.)

2.2) BL files

The BL file data structure has been extended and the BL file format
has been changed slightly. As previously, everything is stored in
log records:

       <length> <data>

       <length> is an integer telling the number of bytes in <data>

       From now on, there will be a record at the beginning of the
       file giving the file format version. This record will have
       length two and the <data> field will be an integer telling
       the version of the log file. The present version is number 2.

       The remaining records in the file have BL structures as <data>

        /* BL structure for keeping statistics. Cleared hourly. */
        struct STAT_STRUCT {
          /* Time at which log entry was written. */
          time_t log_time;

          /* command counters */
          long nHolefills;
          long nStartFile;
          long nEndFile;

          long nNoFile;   /* No -2 */
          long nNoRoom;   /* No -1 */
          long nNotOK;    /* No -3 */

          /* nb are byte counters */
          long nbRequested;    /* bytes in all requests added to queue */
          long nbOverwrite;    /* removed by another request from same stn */
          long nbUnfresh;      /* removed from queue after 10 minutes */
          long nbPfhErr;       /* removed because PFH couldn't be read. */
          long nbFopenErr;     /* removed because file couldn't be opened. */
          long nbEnd;          /* removed from queue by file end commands */
          long nbTransmitted;  /* actually transmitted */

          long nhRequested;  /* holes in hole fill requests */
                             /* (not directory fills) */

          long nDirReqs;     /* dir fill requests */
          long nbDirTxd;     /* bytes of dirs transmitted */

          /* ticks Count time devoted to various actions */
          /* a tick is 10 msec */
          long ticksDir;  /* spent sending directories */
          long ticksData; /* spent sending data */

          /* Count calls heard this hour. */
          int CallsHeard;
        };
The BL logs are written roughly every hour, though this can be changed
by ground command. A log will always be written so that the
ticksData, TicksDir, nbDirTxd and nbTransmitted are consistant with
one another. I.E. you can calculate dir and data throughput using the
ticks numbers.

2.3) The PBLIST Transmission

The PBLIST message has been slightly modified. The list
message has two functions; it is an invitation to transmit, and it is
an indication of who is on the list. In the past, all list messages
were transmitted to "PBLIST." From now on, there will be three
possible callsigns:

   CALL         MEANING
   ------       -------
   PBLIST       Invites all groundstations not listed to send their
                pending requests.
   PBFULL       Shows the list, but is not an invitation to send new requests.
   PBCTRL       Indicates that PBP is in control mode. Only the control
                station can send requests.

All versions of PB will respond correctly to these messages, simply
because PB checks for the destination call "PBLIST" before processing
the list packet. All other groundstation software should conform to this
standard (I think that NET already does).

The "PBFULL" packet will be transmitted whenever there are more than X
stations in the list. X can be varied from the ground, and will be used
for some experiments.

Jeff Ward, G0SUL

P.S. There have already been some preliminary results from the new
logging features. On 20 April, 150 stations used UO-22's Broadcast
services. This is about 3 times the number of stations who use the
FTL0 upload service on an average day. The program CLOGDISP is
included here for you to display the CL files.


From      : g0sul
To        : all
Title     : PB FULL message
Keywords  : PB
Uploader  : G0SUL
Uploaded  : Sat May 15 12:58:47 1993
__________________________
When the PB list is full, the satellite will now send the PB list message
to the address PBFULL rather than the usual PBLIST address. This means
that the groundstation program PB.EXE will not send a request which is
guaranteed to get NO -1 response.

Please be sociable and do not try to defeat this mechanism. It might
even help both downlink and uplink throughput.

JWW

FROM G0SUL 26-6-93

I'm making an experiment to see if having a contention free uplink
generally helps the stations uploading messages to FTL0. To do this
I have introduced a link between the PBLIST message and the FTL0 server.
If anyone is uploading messages to FTL0, then the PBLIST message will
come out with the address "PBWAIT" unless the PB list is actually empty.
This will stop automated stations from making PB requests while uploads
are going on. This is a temporary experiment; it will be most meaningful
if people do not override the automatic operation of PB ever. Thank you.
JWW